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Abstract 

We apply the Gurevich Abstract State Machine methodology to a benchmark specification problem 
of Broy and Lamport. 

As part of the Dagstuhl Workshop on Reactive Systems, Manfred Broy and Leslie Lamport proposed a 
"Specification Problem" [El. The problem calls for the specification and validation of a small distributed 
system dealing with a remote procedure call interface. Broy and Lamport invited proponents of different 
formal methods to specify and validate the system, in order to compare the results of different methods on 
a common problem. 

We take up the challenge and specify the problem using the Gurevich abstract state machine (ASM) 
methodology. This paper is self-contained. In Section 1, we present an introduction to Gurevich abstract state 
machines, including real-time machines. The remaining sections contain the original problem description of 
Broy and Lamport, interspersed with our ASM specifications and validations. 

Acknowledgements. The suggestion to give a ASM solution to this problem was made by Egon Borger 
and Yuri Gurevich; in particular, Yuri Gurevich actively contributed to an early version of the work 
Leslie Lamport made comments on an early draft of this work; Chuck Wallace made comments on a later 
draft. 

1 Gurevich Abstract State Machines 

Gurevich abstract state machines, formerly known as evolving algebras or ealgebras, were introduced in Q; 
a more complete definition (including distributed aspects) appeared in ||. A discussion of real-time ASMs 
appeared most recently in (J]. 



We present here a self-contai ned introduction to ASMs. Sections |l.l| through |l.4| describe distributed 
ASMs (adapted from ||); section [L~5| describes real-time ASMs. Those already familiar with ASMs may skip 
ahead to section @. 



1.1 States 

The states of a ASM are simply the structures of first-order logic, except that relations are treated as 
Boolean- valued functions. 

A vocabulary is a finite collection of function names, each with a fixed arity. Every ASM vocabulary 
contains the following logic symbols: miliary function names true, false, undef, the equality sign, (the names 
of) the usual Boolean operations, and (for convenience) a unary function name Bool. Some function symbols 
(such as Bool) are tagged as relations; others may be tagged as external. 

* University of Michigan EECS Department Technical Report CSE-TR-320-96. 

thugginsOeecs. umich.edu. Partially supported by ONR grant N00014-94-1-1182 and NSF grant CCR-95-04375. 
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A state S of vocabulary T is a non-empty set X (the superuniverse of S), together with interpretations of 
all function symbols in T over X (the basic functions of S). A function symbol / of arity r is interpreted as 
an r-ary operation over X; if r = 0, / is interpreted as an element of X. The interpretations of the function 
symbols true, false, and undef are distinct, and are operated upon by the Boolean operations in the usual 
way. 

Let / be a relation symbol of arity r. We require that (the interpretation of) / is true or false for every 
r-tuple of elements of S. If / is unary, it can be viewed as a universe: the set of elements a for which /(a) 
evaluates to true. For example, Bool is a universe consisting of the two elements (named) true and false. 

Let / be an r-ary basic function and Uq, ■ ■ ■ , U r be universes. We say that / has type U\ x . . . x U r — > Uo 
in a given state if f{x) is in the universe Uq for every x € U\ x . . . x U r , and f{x) has the value undef 
otherwise. 

1.2 Updates 

The simplest change that can occur to a state is the change of an interpretation of one function at one 
particular tuple of arguments. We formalize this notion. 

A location of a state S is a pair £ = (/, x) , where / is an r-ary function name in the vocabulary of S and 
x is an r-tuple of elements of (the superuniverse of) S. (If / is nullary, £ is simply /.) An update of a state 
S is a pair {£, y), where £ is a location of S and y is an element of S. To fire a at S, put y into location £; 
that is, if £ = (f,x), redefine S to interpret f(x) as y and leave everything else unchanged. 

1.3 Transition Rules 

We introduce rules for describing changes to states. At a given state S whose vocabulary includes that of a 
rule R, R gives rise to a set of updates; to execute R at S, fire all the updates in the corresponding update 
set. We suppose throughout that a state of discourse S as a sufficiently rich vocabulary. 
An update instruction R has the form 

/(ti, t2, • • ■ , t n ) •'= to 

where / is an r-ary function name and each U is a term. (If r = 0, we write / := to rather than /() := to-) The 
update set for R contains a single update (£, y), where y is the value (to)s of to at S, and £ = (/, (xi, . . . , x r )), 
where Xi — (U)s- In other words, to execute R at S, set f(x\, . . . , x n ) to y, where X{ is the value of U at S 
and y is the value of t at S. 

A block rule R is a sequence R\, . . . , R n of transition rules. To execute R at S, execute all the Ri at S 
simultaneously. That is, the update set of R at S is the union of the update sets of the Ri at S. 

A conditional rule R has the form 

if g then i?o else R\ endif 

where g (the guard) is a term and Rq, Ri are rules. The meaning of R is the obvious one: if g evaluates to 
true in S, then the update set for R at S is the same as that for i? at S; otherwise, the update set for R 
at S is the same as that for R\ at S. 
A choice rule R has the form 

choose v satisfying c(v) 

R (v) 
endchoose 

where v is a variable, c(v) is a term involving variable v, and Ro(v) is a rule with free variable v. This rule 
is nondeterministic. To execute R in state S, choose some element of a of S such that c(a) evaluates to true 
in S, and execute rule Rq, interpreting v as a. If no such element exists, do nothing. 
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1.4 Distributed Machines 

In this section we describe how distributed ASMs evolve over time. The intuition is that each agent of 
a distributed ASM operates in a sequential manner, and moves of different agents are ordered only when 
necessary (for example, when two agents attempt contradictory updates). 

How do ASMs interact with the external world? There are several ways to model such interactions. One 
common way is through the use of external functions. The values of external functions are provided not by 
the ASM itself but by some external oracle. The value of an external function may change from state to 
state without any explicit action by the ASM. If S is a state of a ASM, let S~ be the reduct of S to (the 
vocabulary) of non-external functions. 

Let T be a vocabulary containing the universe agents, a unary function Mod, and a miliary function Me. 
A distributed ASM program IT of vocabulary T consists of a finite set of modules, each of which is a transition 
rule over the vocabulary T. Each module has a unique name different from T or Me. The intuition is that 
a module is a program to be executed by one or more agents. 

A (global) state of II is a structure S of vocabulary T — {Me}, where different module names are 
interpreted as different elements of S and Mod maps module names to elements of agents and all other 
elements to undef. If Mod(a) — M, we say that a is an agent with program M. 

For every agent a, View ,(5) is the reduct of S to the functions mentioned in a's program Mod(a), 
extended by interpreting the special function Me as a. View a (S) can be seen as the local state of agent a 
corresponding to the global state S. To fire an agent a at a state S, execute Mod(a) at state View a (S). 

A run of a distributed ASM program II is a triple (M,A,a), satisfying the following conditions: 

1. M, the set of moves of p, is a partially ordered set where every set {y : v < p} is finite. 

Intuitively, v < p means that move v occurs before move p. If M is totally ordered, we call p a 
sequential run. 

2. A assigns agents (of So) to moves such that every non-empty set {p : A(p) — a} is linearly ordered. 

Intuitively, A(p) is the agent which performs move p; the condition asserts that every agent acts 
sequentially. 

3. a maps finite initial segments of M (including 0) to states of IT. 

Intuitively, <j(X) is the result of performing all moves of X; c(0) is the initial state So- 

4. (Coherence) If p, is a maximal element of a finite initial segment Y of M, and X = Y — {p}, then 
c(Y)~ is obtained from a(X) by firing A(p) at c{X). 

1.5 Real-Time Machines 

Real-time ASMs are an extension of distributed ASMs which incorporate the notion of real-time. The notion 
of state is basically unchanged; what changes is the notion of run. The definitions presented here are taken 
from jl); they may not be sufficient to model every real-time system but certainly suffice for the models to 
be presented in this paper. 

Let T be a vocabulary with a universe symbol Reals which does not contain the miliary function CT. Let 
T + be the extension of T to include CT. We will restrict attention to T + -states where the universe Reals 
is the set of real numbers and CT evaluates to a real number. Intuitively, CT gives the current time of a 
given state. 

A pre-run R of vocabulary T + is a mapping from the interval [0, oo) to states of vocabulary T + satisfying 
the following requirements, where p(t) is the reduct of R(t) to T: 

1. The superuniverse of every R(t) is that of R(0); that is, the superuniverse does not change during the 
pre-run. 

2. At every R(t), CT evaluates to t. CT represents the current (global) time of a given state. 
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3. For every r > 0, there is a finite sequence = to < t\ < . . . < t n = r such that if U < a < (3 < U+i, 
then p(a) — p{(3). That is, for every time t, there is a finite, discrete sequence of moments prior to t 
when a change occurs in the states of the run (other than a change to CT) . 

In the remainder of this section, let R be a pre-run of vocabulary T* and pit) be the reduct of R(t) to 
T. p(t+) is any state p(t + e) such that e > and p(t + S) = p(t + e) for all positive S < e. Similarly, if t > 0, 
then pit—) is any state pit — e) such that < e < t and p(t — 5) = p[t — e) for all positive 6 < e. 

A pre-run R of vocabulary T + is a run of II if it satisfies the following conditions: 

1. If p(t+) differs from p(t) then p(t+) is the T-reduct of the state resulting from executing some modules 
Mi, . . . , Mk at R(t). All external functions have the same values in p(t) and p{t+). 

2. If t > and p(t) differs from pit—) then they differ only in the values of external functions. All internal 
functions have the same values in pit—) and pit). 

2 The Procedure Interface 

The Broy-Lamport specification problem begins as follows: 

The problem calls for the specification and verification of a series of components. Components 
interact with one another using a procedure-calling interface. One component issues a call to 
another, and the second component responds by issuing a return. A call is an indivisible (atomic) 
action that communicates a procedure name and a list of arguments to the called component. A 
return is an atomic action issued in response to a call. There are two kinds of returns, normal 
and exceptional. A normal call returns a value (which could be a list) . An exceptional return also 
returns a value, usually indicating some error condition. An exceptional return of a value e is 
called raising exception e. A return is issued only in response to a call. There may be "syntactic" 
restrictions on the types of arguments and return values. 

A component may contain multiple processes that can concurrently issue procedure calls. More 
precisely, after one process issues a call, other processes can issue calls to the same component 
before the component issues a return from the first call. A return action communicates to the 
calling component the identity of the process that issued the corresponding call. 

The modules in our ASM represent components; each component is described by one module. The 
universe Components contains (elements representing) the modules of the system. 

The agents in our ASM represent processes; just as each component can have several processes, so a 
given module can belong to several agents. The universe agents contains elements representing the agents 
of the system. A function Component: agents —* modules indicates the component to which a given process 
belongs]]. 

Calls and returns are represented by the execution of transition rules which convey the appropriate 
information between two processes. The following unary functions are used to transmit this information, 
where the domain of each function is the universe of agents: 

• CallMade: whether or not this process made a call while handling the current call 

• CallSender: which process made a call most recently to this process 

• CallName: what procedure name was sent to this process 

• CallArgs: what arguments were sent to this process 

• CallReply: what type of return (normal or exceptional) was sent to this process 

• CallReply Value: what return value was sent to this process 

We use two macros (or abbreviations), CALL and RETURN, which are used to make the indivisible 
(atomic) actions of issuing calls and returns. Each macro performs the task of transferring the relevant 
information between the caller and callee. The definitions of CALL and RETURN are given in Figure |l|. 

1 For those familiar with the Lipari Guide, this is a renaming of the function Mod. 
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Abbreviation: CALL(procname, arglist, destination) 

choose p satisfying (Component(p)= destination and CallSender(p) =undef ') 

CallSender(p) := Me 

CallName(p) := procname 

CallArgs(p) := arglist 

CallMade(Me) := true 

CallReply(Me) := undef 

CallReplyValue(Me) := undef 
endchoose 

Abbreviation: RETURN(type, value) 

CallReply(CallSender(Me)) := type 
CallReplyValue(CallSender(Me)) := value 
CallSender(Me) := undef 
CallName(Me) := undef 
CallArgs(Me) := undef 
CallMade(Me) — false 



Figure 1: Definitions of the CALL and RETURN abbreviations. 



3 A Memory Component 



The Broy-Lamport problem calls for the specification of a memory component. The requirements arc as 
follows: 



The component to be specified is a memory that maintains the contents of a set MemLocs of 
locations. The contents of a location is an element of a set MemVals. This component has two 
procedures, described informally below. Note that being an element of MemLocs or MemVals is 
a "semantic" restriction, and cannot be imposed solely by syntactic restrictions on the types of 
arguments. 



Name 
Arguments 
Return Value 
Exceptions 

Description 

Name 
Arguments 

Return Value 
Exceptions 



Description 



Read 

loc : an element of MemLocs 
an element of MemVals 

BadArg : argument loc is not an element of MemLocs. 
MemFailure : the memory cannot be read. 
Returns the value stored in address loc. 

Write 

loc : an element of MemLocs 
val : an element of MemVals 
some fixed value 

BadArg : argument loc is not an element of MemLocs, or 

argument val is not an element of MemVals. 
MemFailure : the write might not have succeeded. 
Stores the value val in address loc. 



The memory must eventually issue a return for every Read and Write call. 

Define an operation to consist of a procedure call and the corresponding return. The operation 
is said to be successful iff it has a normal (nonexceptional) return. The memory behaves as if it 
maintains an array of atomically read and written locations that initially all contain the value 
InitVal, such that: 

• An operation that raises a BadArg exception has no effect on the memory. 
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• Each successful Read (7) operation performs a single atomic read to location I at some time 
between the call and return. 

• Each successful Write (I, v) operation performs a sequence of one or more atomic writes of 
value v to location / at some time between the call and return. 

• Each unsuccessful Write(Z, v) operation performs a sequence of zero or more atomic writes 
of value v to location I at some time between the call and return. 

A variant of the Memory Component is the Reliable Memory Component, in which no MemFailure 
exceptions can be raised. 

Problem 1 (a) Write a formal specification of the Memory component and of the Reliable 
Memory component. 

(b) Either prove that a Reliable Memory component is a correct implementation of a Memory 
component, or explain why it should not be. 

(c) If your specification of the Memory component allows an implementation that does nothing 
but raise MemFailure exceptions, explain why this is reasonable. 

3.1 ASM Description 

As suggested by the description, our ASM has universes MemLocs and MemVals, and a function Memory: 
MemLocs — > Mem Vals which indicates the contents of memory at a given location. We also have the following 
universes and associated functions: 

• procnames: names of procedures to be called. Includes the distinguished elements read and write. 

• lists: lists of elements in the superuniverse. Unary functions First, Second extract the corresponding 
element from the given list. 

• returntypes: types of returns to be issued. Includes the distinguished elements normal and exception. 

• exceptions: types of exceptions to be issued. Includes the distinguished elements BadArg and Mem- 
Failure. 

• values: types of return values. Includes the universe MemVals as well as a distinguished element Ok 
(used for returns from successful write operations, where the nature of the return value is unimportant). 

In addition, we use two Boolean-valued external functions, Succeed and Fail. The intuition is that Fail 
indicates when a component should unconditionally fail, while Succeed indicates when a component may 
succeed during an attempt to write to memory. We require that Succeed cannot be false forever; that is, for 
any state a in which Succeed is false, Succeed cannot be false in every successor state p > a. This ensures 
that every operation eventually terminates. 

3.2 Component Program 

Our ASM contains an unspecified number of agents comprising the memory component. The program for 
these agents is shown in Figure ^[ 

In order to make this evolving algebra complete, we need a component which makes calls to the memory 
component. Of course, we don't wish to constrain how the memory component is called, other than that the 
CALL interface is used. 

Our ASM contains an unspecified number of processes implementing a calling component, whose simple 
program is shown in Figure ||. 

This component uses several external functions. MakeCall returns a Boolean value indicating whether a 
call should be made at a given moment. GetName and GetArgs supply the procedure name and argument 
list to be passed to the memory component. MemComponent is a static (non-external) function indicating 
the memory component. 

We define an operation to be the linearly-ordered sequence of moves beginning with the execution of 
CALL by one component and ending with the execution of RETURN by the component which received the 
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if CallName(Me)—read then 

if MemLocs(First(CallArgs(Me)))=false then RETURN (exception, BadArg) 
elseif Fail then RETURN (exception, MemFailure) 
else RETURN (normal, Memory (First(CallArgs(Me)J)) 
endif 

elseif CallName(Me)=write then 

if MemLocs(First(CallArgs(Me)))=false or MemVals(Second(CallArgs(Me)))=false then 

RETURN (exception, BadArg) 
elseif Fail then RETURN (exception, MemFailure) 
else 

Memory •(First(CallArgs(Me))) := Second(CallArgs(Me)) 
if Succeed then RETURN (normal, Ok) endif 
endif 
endif 



Figure 2: Memory component program. 



if MakeCall then CALL(GetName, GetArgs, MemComponent) endif 



Figure 3: Calling component program. 

call. In the simplest case, this sequence has exactly two moves (an execution of CALL followed immediately 
by an execution of RETURN). 

A reliable memory component is identical to a memory component except that the external function Fail 
is required to have the value false at all times. Thus, the MemFailure exception cannot be raised. 

3.3 Correctness 

We now show that the Memory and Reliable Memory components specified above satisfy the given require- 
ments. The Broy-Lamport problem does not require us to demonstrate that the specification in fact satisfies 
the given requirements; nonetheless, it seems quite reasonable and important to do so. 

Lemma 1 Every operation resulting in a BadArg exception has no effect on the memory. 

Proof. Observe from the component specification above that any such operation consists of exactly two 
moves: the original call to the Memory component, and the move which raises the BadArg exception. 
Observe further that the rule executed by the Memory component to issue the BadArg exception neither 
reads nor alters the function Memory. QED. 

Lemma 2 Every successful Read (7) operation performs a single atomic read to location I at some time 
between the call and return. 

Proof. Observe from the component specification above that any such operation consists of exactly two 
moves: the original call to the Memory component, and the move which issues the successful return. Observe 
further that the rule executed by the Memory component to issue the successful return accesses the Memory 
function exactly once, when evaluating Memory (First(CallArgs(Me))). QED. 

Lemma 3 Every successful Write(7, v) operation performs a sequence of one or more atomic writes of value 
v to location I at some time between the call and return. 
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Proof. Observe from the component specification above that any such operation consists of several moves: 
the original call to the Memory component, and one or more moves which write value v to location I. The 
last of these writing moves also issues the successful return. QED. 

Lemma 4 Every unsuccessful Write(7, v) operation performs a sequence of zero or more atomic writes of 
value v to location I at some time between the call and return. 

Proof. Observe from the component specification above that any such operation consists of several moves: 
the original call to the Memory component, zero or more moves which write value v to location I, and the 
move which returns an exception (either MemFailure or BadArg). QED. 

We thus have immediately: 

Theorem 1 The ASM specification of the memory component correctly implements the requirements given 
for memory components. 

As to the other issues we are asked to consider: 

• It is trivial to see that a reliable memory component is a correct implementation of a memory com- 
ponent; all of the proofs above apply to reliable memory components, other than the fact that Write 
operations cannot raise MemFailure exceptions. 

• Our specification does allow for a memory component to return only MemFailure exceptions. It seems 
reasonable to allow this behavior; it corresponds to the real-world scenario where a memory component 
is irreparable or cannot be reached through the network. 



4 The RPC Component 

The Broy-Lamport problem calls for the specification of an RPC (for "remote procedure call") component. 
Its description is as follows: 

The RPC component interfaces with two environment components, a sender and a receiver. 
It relays procedure calls from the sender to the receiver, and relays the return values back to the 
sender. Parameters of the component are a set Procs of procedure names and a mapping ArglMum, 
where ArglMum(p) is the number of arguments of each procedure p. The RPC component contains 
a single procedure: 

Name RemoteCall 

Arguments proc : name of a procedure 

args : list of arguments 
Return Value any value that can be returned by a call to proc 
Exceptions RPCFailure : the call failed 

BadCall : proc is not a valid name or args is not a 

syntactically correct list of arguments for proc. 

Raises any exception raised by a call to proc 
Description Calls procedure proc with arguments args 

A call of RemoteCall(proc, args) causes the RPC component to do one of the following: 

• Raise a BadCall exception if args is not a list of ArgNum(proc) arguments. 

• Issue one call to procedure proc with arguments args, wait for the corresponding return 
(which the RPC component assumes will occur) and either (a) return the value (normal or 
exceptional) returned by that call, or (b) raise the RPCFailure exception. 

• Issue no procedure call, and raise the RPCFailure exception. 

The component accepts concurrent calls of RemoteCall from the sender, and can have multiple 
outstanding calls to the receiver. 

Problem 2 Write a formal specification of the RPC component. 
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4.1 ASM Description 

We add a new distinguished element remotecall to the universe of procnames, and distinguished elements 
BadCall and RPCFailure to the universe of exceptions. We use the standard universe of integers in conjunc- 
tion with the following functions: 

• ArgNum: procnames — > integers indicates the number of arguments to be supplied with each procedure 
name 

• Length: lists — > integers returns the length of the given argument list 

A distinguished element Destination indicates the component to which this RPC component is supposed to 
forward its procedure call. 

The ASM program for the RPC component is shown in Figure ||. 



if CallName(Me) — remotecall then 

if Length(Second(CallArgs(Me))) ^ ArgNum(First(CallArgs(Me))) then 

RETURN (exception, BadCall) 
elseif CallMade(Me)=false then 

if Fail then RETURN (exception, RPCFailure) 

else CALL(First(CallArgs(Me)),Second(CallArgs(Me)), Destination) 
endif 

elseif CallReply(Me) ^ undef then 

if Fail then RETURN (exception, RPCFailure) 
else RETURN (CallReply (Me), CallReplyValue(Me)) 
endif 

endif 
endif 



Figure 4: RPC component program. 

To complete the specification, we need to supply a component to call the RPC component (such as our 
caller component from the previous section) and a component for the RPC component to call (such as the 
memory component from the previous section). 

Again, we are not asked to prove that the specification satisfies the requirements given above; the proof 
is similar to that given in the last section and is omitted. 

5 Implementing The Memory Component 

The Broy-Lamport problem calls us to create a memory component using a reliable memory component and 
an RPC component. The requirements are as follows: 

A Memory component is implemented by combining an RPC component with a Reliable 
Memory component as follows. A Read or Write call is forwarded to the Reliable Memory by 
issuing the appropriate call to the RPC component. If this call returns without raising an 
RPCFailure exception, the value returned is returned to the caller. (An exceptional return causes 
an exception to be raised.) If the call raises an RPCFailure exception, then the implementation 
may either reissue the call to the RPC component or raise a MemFailure exception. The RPC 
call can be retried arbitrarily many times because of RPCFailure exceptions, but a return from 
the Read or Write call must eventually be issued. 

Problem 3 Write a formal specification of the implementation, and prove that it correctly 
implements the specification of the Memory component of Problem 1. 
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if CallName(Me) ^ undef then 

if CallMade(Me) = false then 

CALL(CallName(Me), CallArgs(Me), RPC Component) 
elseif CallReply(Me) ^ undef then 

if (CallReply(Me) ^ exception) or (CallReplyValue(Me) ^ RPCFailure) then 

RETURN(CallReply(Me ), CallReply Value(Me )) 
elseif Retry then CALL(CallName(Me), CallArgs(Me), RPCComponent) 
else RETURN (exception, MemFail) 
endif 
endif 
endif 



Figure 5: Implementing component program. 

Our implementation includes three modules. Two of the modules are, naturally, instances of the reliable 
memory component and the RPC component. The program for the third module is shown in Figure [5| 

The component uses an external Boolean-valued function Retry, which indicates whether or not an 
RPCFailure exception should result in another attempt to send the call to the RPC component. The distin- 
guished element RPCComponent indicates the RPC component module; the distinguished element MemFail 
is a member of the universe of exceptions. We require that Retry cannot force the component to resend the 
call forever; more precisely, for any given agent, and for any state a such that CallReply (Me)— exception, 
CallReply Value(Me) =RPCFailure, and Retry —true, not every successor state p > a which satisfies CallRe- 
ply (Me)— exception and CallReplyValue(Me) —RPCFailure also satisfies Reply=true. 

It remains to prove that this implementation is correct. We consider the four original requirements for 
memory components. 

Lemma 5 Every operation resulting in a BadArg exception has no effect on the memory. 

Proof. From the module specifications given above, we observe that an operation resulting in a BadArg 
exception consists of the following sequence of moves: 

• a call from the caller component to the implementing component given above 

• a call from the implementing component to the RPC component 

• a return of the BadArg exception from the RPC component to the implementing component 

• a return of the BadArg exception from the implementing component to the caller component 

An examination of the rules involved shows that the Memory function is neither read nor updated in any of 
these moves. QED. 

Lemma 6 Every unsuccessful Read (7) operation performs zero or more atomic reads to location I at some 
time between the call and return. 

This is not one of the original requirements, but the result is used later. 

Proof. Fix a sequence of moves which comprise an unsuccessful Read operation. The first element of this 
sequence is the call from the caller component to the implementation component; the last element of this 
sequence is the corresponding exceptional return. 

The moves between these two elements can be divided into one or more disjoint subsequences of moves, 
each of which is an operation of the RPC component resulting in an exceptional return. There are several 
cases. 

• The RPC component may raise an RPCException without calling the reliable memory component. In 
this case, Memory is never accessed. 
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• The RPC component may make a call to the reliable memory component, ignore the return value, and 
raise an RPCException. In this case, as was shown earlier, Memory is accessed exactly once. 

• The RPC component may make a call to the reliable memory component and pass the (exceptional) 
return value to the caller. In this case, Memory is never accessed. 

Thus, every operation of the RPC component may result in zero or one atomic reads of location I in Memory. 
Consequently, the entire sequence of RPC component calls may result in zero or more atomic reads of location 
I in Memory. QED. 

Lemma 7 Every successful Read(Z) operation performs one or more atomic reads to location I at some time 
between the call and return. 

Note that this is different from the original requirement: that a successful Read (I) operation performs 
exactly one atomic read of location I. The described composition given above cannot possibly satisfy this 
requirement. To sec this, observe that the RPCFailure exception can be raised by the RPC component 
before any call to the Reliable Memory component (in which case no read of I occurs) or after it calls the 
Reliable Memory component (in which case a single read of I has occurred). The implementation component 
above cannot tell the difference between these two conditions; since it is to retry the call some number of 
times before failing, we cannot ensure that a read to I only occurs once if retries are to be permitted. We 
choose to allow retries and proceed to prove the modified requirement. 

Proof. As in the previous lemma, the first and last move in a successful Read(Z) operation are the corre- 
sponding calls and return between the environment component and the implementation component. The 
moves between these two elements can be divided into one or more disjoint subsequences of moves; the last 
of these subsequences is a successful RPC operation, while the remainder (if any) are unsuccessful RPC 
operations. 

The previous lemma shows that a sequence of unsuccessful RPC operations for a Read(/) call results in 
zero or more atomic reads to I. A similar argument shows that a successful RPC call results in a single 
atomic read to I; the result follows. QED. 

Lemma 8 Every unsuccessful Write(Z, v) operation performs a sequence of zero or more atomic writes of 
value v to location I at some time between the call and return. 

Lemma 9 Every successful Write(Z, v) operation performs a sequence of one or more atomic writes of value 
v to location I at some time between the call and return. 

The proof of these lemmas are similar to those for Read operations and are thus omitted. Combining 
these lemmas yields the desired conclusion: 

Theorem 2 The ASM specification given correctly implements the requirements given for a memory com- 
ponent, except that Read operations may perform more than one atomic read between the call and return. 

6 A Lossy RPC Component 

The Broy-Lamport problem calls for the specification of a Lossy RPC Component, whose requirements are 
as follows: 

The Lossy RPC component is the same as the RPC component except for the following 
differences, where 5 is a parameter. 

• The RPCFailure exception is never raised. Instead of raising this exception, the RemoteCall 
procedure never returns. 

• If a call to RemoteCall raises a BadCall exception, then that exception will be raised within 
S seconds of the call. 
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• If a RemoteCall(j>, a) call results in a call of procedure p, then that call of p will occur within 
(5 seconds of the call of RemoteCall. 

• If a RemoteCall(p, a) call returns other than by raising a BadCall exception, then that return 
will occur within S seconds of the return from the call to procedure p. 

Problem 4 Write a formal specification of the Lossy RPC component. 

Clearly the requirements suggest the need for a modeling environment which includes time. We use the 
real-time ASM model presented in Q and reviewed in Section 1. 

Implicit in the description above is the fact that every call and return occurs at a specific moment in 
time. Consequently, our ASM descriptions of calls and returns will need to record the time at which each 
call and return occurs. Our ASM will make use of several new unary functions: 

• CalllnTime: the time that a call was received by the given process 

• CallOutTime: the time that a call was placed by the given process 

• ReturnTime: the time that a return was received by the given process 

The new definitions for the CALL and RETURN abbreviations are shown in Figure ^. 



Abbreviation: CALL(procname, arglist, destination) 

choose p satisfying (Component(p)— destination and CallSender(p) =undej ') 

CallSender(p) := Me 

CallName(p) :— procname 

CallArgs(p) := arglist 

CalllnTime(p) := CT 

ReturnTime(p) := undef 

CallOutTime (Me) := CT 

CallMade(Me) := true 

CallReply(Me) := undef 

CallReplyValue(Me) :— undef 
endchoose 

Abbreviation: RETURN(type, value) 

CallReply(CallSender(Me)) := type 
CallReplyValue(CallSender(Me)) := value 
ReturnTime(CallSender(Me)) := CT 
CallOutTime(CallSender(Me)) := undef 
CallInTime(CallSender(Me)) := undef 
CallSender(Me) :— undef 
CallName(Me) :— undef 
CallArgs(Me) :— undef 
CallMade(Me) := false 



Figure 6: The new CALL and RETURN abbreviations. 

The ASM program for the lossy RPC component is given in Figure ^. It uses a distinguished element 5 
as specified in the problem description. 

Lemma 10 Every operation of the Lossy RPC component has one of the following forms: 
• A call which results in no call of the destination component and no return to the caller 
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if CallName(Me) = remotecall then 

if CalllnTime(Me) ^ undef and CallOutTime(Me)=undef then 
if CT > CalllnTime(Me) +6 then 

elseif Length(Second(CallArgs(Me))) ^ ArgNum(First(CallArgs(Me) ) ) then 
RETURN (exception, BadCall) 

else 

CALL(First(CallArgs(Me)),Second(CallArgs(Me)), Destination) 

endif 

elseif ReturnTime(Me) / imcfe/ then 

if CT > ReturnTime(Me) +5 then Fvl/L 

else RETURN( CallReply(Me), CallReplyValue(Me)) 

endif 
endif 
endif 

where FAIL abbreviates 

CallName(Me) := false 
CallArgs(Me) := false 
CallMade(Me) := false 
CalllnTime(Me) := undef 
CallOutTime(Me) := undef 
ReturnTime(Me) := undef 



Figure 7: Lossy RPC component program. 

• A call which results in a BadCall exception being raised within 5 seconds of the call 

• A call which results in a call of the destination component within 5 seconds of the call, but results in 
no return to the caller 

• A call which results in a call of the destination component within S seconds of the call, whose return is 
relayed to the caller within S seconds of the return 

This lemma can be easily verified by analysis of the program above. The key point to notice is that any call 
or return action by the Lossy RPC component is guaranteed to occur within <5 seconds of the event which 
prompted that action; if too much time passes, the rules ensure that the FAIL abbreviation will be executed 
instead of the call or return action. 

7 The RPC Implementation 

The Broy-Lamport calls for one final implementation, whose requirements are as follows: 

The RPC component is implemented with a Lossy RPC component by passing the RemoteCall 
call through to the Lossy RPC, passing the return back to the caller, and raising an exception if 
the corresponding return has not been issued after 25 + e seconds. 

Problem 5 (a) Write a formal specification of this implementation. 

(b) Prove that, if every call to a procedure in Procs returns within e seconds, then the 
implementation satisfies the specification of the RPC component in Problem 2. 

The implementation module is shown in Figure |^. It uses a few new functions whose meaning should be 
clear by now. 
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if CallName(Me) ^ undef then 

if CallMade(Me) = false then 

CALL(CallName(Me), CallArgs(Me), LossyRPC) 
elseif CallReply(Me) ^ wide/ and ReturnTime(Me) < CallOutTime(Me) +2S + e then 

RETURN(CallReply(Me), CallReplyValue(Me)) 
elseif (CT > CallOutTime(Me) +2S + e) then 

RETURN (exception, RPCFailure) 
endif 
endif 



Figure 8: RPC implementation component module. 

We combine this implementation module with an instance of the caller module, an instance of the lossy 
RPC module, and an instance of the memory (or reliable memory) Component (so that the lossy RPC 
module has someone to whom it passes calls). We assert that the memory component is bounded with 
bound e. 

Theorem 3 Every operation of the implementation component above has one of the following forms: 

• a call to the LossyRPC component which returns a BadCall exception 

• a call to the LossyRPC component which makes no call to the Memory component; the implementation 
component then returns an RPCFailure exception 

• a call to the LossyRPC component which makes a call to the Memory component, waits for the return 
value from the Memory component, and ignores the return value; the implementation component then 
returns an RPCFailure exception 

• a call to the LossyRPC component which makes a call to the Memory component from the Memory 
component, waits for the return value, and returns the value 

Proof. The previous lemma establishes the behavior of the lossy RPC component, to which the implemen- 
tation component forwards its calls. Notice that any operation which does not result in an BadCall or an 
RPCFailure exception requires an operation between the lossy RPC component and the memory component, 
which by supposition is guaranteed to complete within time e. Notice that further that the lossy RPC 
component must send its call to the memory component within 5 seconds of the call in order to receive any 
return; otherwise, the FAIL abbreviation will be executed, discarding the call. Similarly, the lossy RPC 
component must relay the return value from the Memory component to the implementing component within 
5 seconds of the return in order to return anything at all. Thus, any successful return will occur within 25 + e 
seconds of the original call. The implementing component can thus safely assume that any call to the lossy 
RPC component which has not resulted in a return within that time interval will never have a return, and 
the RPCFailure exception may be safely generated. QED. 
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